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Leading Your Leaders 

BY N. WAYNE HALE, JR. 
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When I was a new NASA employee, my branch chief put together a training class that has been on my 
mind recently. Among the other things he taught us new employees was that we had to lead our leaders. 
That has always been good advice. I’d like to share some of those thoughts and expand on them. 


First of all, remember that your leaders are not very smart. Once 
upon a time some of us might have been smart in certain subjects, 
but that was long ago. Being a manager dulls your technical skills. 

So who is smart? The smartest guy is the person with his 
hand on the tool, running the test or doing the analysis. That 
person has all the information. He or she understands all the 
limitations of the test or analysis. The smart guy knows how the 
part or test or analysis Fits in the context of its surroundings. 

Unfortunately for us managers, the smart guy is almost 
always so intimately connected with the hardware /analysis /test 
that it is hard for him to explain to the rest of us just how it 
works. It is hard for an expert to communicate to a layman, 
especially with all the connotations that give meaning to the 
subject. But the guy doing the work is still the smartest person 
in the world on what the work means. 

In between that smart guy and the upper management 
bosses live the dreaded middle managers. These folks are semi- 
smart: they have some recent experience, they understand part 
of the data, they have gotten the verbal reports unfiltered, and 
they can sometimes go see the test rig or the flight hardware. 
But these middle managers are subject to pressures from the 
personnel department, the “budgeteers,” the schedulers, and 
the paperwork bureaucrats who are so prevalent in our system. 
This causes smart technical folks to lose their technical 
abilities when they become middle managers. So the middle 
managers are only semi-smart, and, worse, they control the 
communication chain — the middle managers determine what 
gets told and to whom. 

The top leaders are supposedly the decision makers, but they 
are really not smart. Once they were real workers and perhaps 
were really smart, but that was so long ago that they most likely 
used slide rules. (I sure did.) They haven’t solved an integral 
equation in twenty years nor have they used a torque wrench 
in decades (except to break the lawnmower last summer, like 
I did). Meanwhile, senior leaders spend most of their waking 
hours thinking deep thoughts, subjects like what are the goals 


of the Agency for the next twenty-five years, how should the 
governance model work (and what the heck its about), and how 
should we deal with congressional staffers or the White House? 
Brain-numbing stuff. 

So how do the smart guys get the decision makers to make the 
right decisions? Simple: The smart guys have to lead their leaders. 

Don’t be mistaken: everybody I have met in this outfit has 
their heart in the right place. Everybody wants the mission to 
succeed and the crew to come home safely. But sometimes the 
right way to reach those goals is complicated. 

To make it easier, here are some tips on how to lead 
your leaders: 

1. REMEMBER TO EXPLAIN THE PROBLEM. 

Even though working on a problem has been your primary 
effort for the past year, your leadership may have heard 
about this once in a briefing a decade ago. Now they are 
basically clueless. Pretend that you are talking to your 
daughter’s fifth-grade class. Explain how your complicated 
gizmo works. If possible, do not use acronyms. Define 
your terms. Put your work in context. Assume your leader 
has no idea what you do, who you work for, or what your 
gizmo does. That is a good place to start. 

2. TELL YOUR LEADER HOW THIS PROBLEM 
SHOULD BE SOLVED. 

Remember, taking the next century to study the problem 
or spending the Gross National Product to invent a 
new solution are probably not going to be acceptable 
solutions. Real engineers and technicians build real 
hardware that works in the real world in a reasonable 
manner within a reasonable time at a reasonable cost. 
True, skimping on time or money can cause mistakes, 
but folks whose gizmos are delayed unreasonably or cost 
more than is practical get their programs canceled, force 
the business into bankruptcy, or give the market over to 
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the competition. Real engineers and technicians always 
consider cost and schedule in their work. 

3. DON’T CRY WOLF. 

If you repeatedly tell top management the world is going 
to end, and then it doesn’t end, your credibility will suffer. 
Worst-case analysis or worst-on-worst tests are mandatory 
and results from them must be reported, but these tests and 
analyses don’t represent what z^/7/ happen. It is not enough to 
demonstrate how badly things might turn out; it is important 
to show how the hardware will most likely perform and put 
the really bad outcomes in the right context. 

4. SOLVE THE PROBLEM. 

Raising questions is important. However, we are in the 
business of doing things. Engineers and technicians are 
paid to get things done. Yes, you have to identify the 
problem, frame the design, identify the tests, perform 
the analysis, and assemble the hardware. But the goal 
is to solve the problem. Nobody ever said flying in space 
was easy. We make it look easy the same way that an 
Olympic champion makes her sport look easy: by 
working hard at improving performance every day. 

5. MIKE GRIFFIN HAS SAID, “NOBODY GETS TO DO 
HOMEWORK PROBLEMS AND PUSH THE PAPER 
UNDER THE DOOR.” 

What that means is that we all have to understand the 
risk relative to the bigger picture. No matter where you 
are on the org chart, you have to understand the context, 
be able to place the risk involved in relation to the risk of 
the alternatives. You don’t understand the risk (or cost, 
schedule, or performance) of the alternatives? Then 
you have homework to do. Be prepared to put your 
recommended solution in relation to the alternatives. 

6. BANISH THE WORDS “WE JUST DON’T KNOW” 

FROM YOUR VOCABULARY. 

When you say those words, you empower dumb upper- 
level managers to make a decision based on their 
inadequate understanding of the problem and on other 
factors (like cost and schedule). Do you really think 


the guy at the end of the table who just came from the 
budget meeting is a better expert than you are on your 
gizmo? No. It is important to say how you are going 
to find out those things you don’t know. If you are the 
smartest guy and you don’t know, at least provide a plan 
on how we will get to a good solution. As a famous 
astronomer once noted, “We don’t know one-tenth of 
one percent about anything.” That’s true, but it doesn’t 
stop us from trying to build things that work. So we 
do what they still teach in engineering school: make 
some reasonable approximations. Neglect the terms that 
provide a relatively small contribution to the answer. 
Give it the best you’ve got. Instead of saying, “we just 
don’t know,” tell your leader what you can do and what 
approach you are going to take, and include a description 
of the variations that may result from your work. 

You can also use some elements of good flight rationale to 
provide to your no t-so -smart leaders. 

First, use expert judgment. After flying this equipment for 
years, hands-on experts have learned a great deal. Judgment, 
honed over a long period from observation of many space flights 
and the operation of our hardware, is valuable. When faced with 
a problem, it is imperative to review the previous history and 


TRUE, SKIMPING ON TIME OR MONEY 
CAN CAUSE MISTAKES, BUT FOLKS 
WHOSE GIZMOS ARE DELAYED 
UNREASONABLY OR COST MORE 
THAN IS PRACTICAL GET THEIR 
PROGRAMS CANCELED ... 
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performance of the hardware. And the opinion of the engineers 
and technicians who have worked with the equipment for many 
years is of incalculable value. On the other hand, using everyday 
experience or the “logic” of folks who are not familiar with the 
specifics of the way the hardware works is worse than useless in 
our business and can lead to the wrong conclusions. 

Next, use analysis. A good analytical tool — verified against 
real-world performance (including all variables), peer reviewed, 
and operated within the limits for which it was intended — is 
a powerful way to understand what could happen. However, 
the output of analysis always contains an error or level of 
uncertainty, and the validity of the analysis output always 
depends on the inputs and assumptions. Assume a worst case 
and you will get one answer. Assume a nominal case and you 
get a different answer. It is important to report all these results 
along with the basic accuracy of the analysis. To conduct an 
analysis without understanding limitations and uncertainties is 
an incomplete analysis. An analysis not anchored in testing or 
an analysis tool used in ways for which it was not designed can 
lead to inaccurate conclusions. A “back of the envelope” analysis 
based on first principles can also be terribly misleading in our 
line of work, where we deal with extreme environments and 
complex mechanisms. 

Better are the results of a well-defined test. Remember 
that a test on a laboratory bench is always an approximation of 
reality, and rules similar to those for good analysis also apply. 
One should always be mindful of Mechelay s rule: “It is better 
to be stupid than to run a stupid test.” Often we try to overtest. 
If a piece of hardware passes an unbelievably difficult test, then 
life is good. More often when an unbelievably difficult test fails, 
we are left with a very long discussion of why and what was 
wrong in the design or execution of the test. Make sure that the 
test is well defined. Even then, it is important to explain to your 
leaders what inherent accuracy (or error) the test conditions or 
equipment have and what the assumptions or initial conditions 
were for the test. Test results without a good understanding of 
the tests accuracy or the pedigree of the test assumptions are 
worth very little. 

Finally, there is flight test data. Always limited, never at 
the edge of the envelope, it still shows how the real hardware 
works in a real and combined environment. Flight experience 
is dangerous because it typically doesn't show how close to 


the edge of the cliff the equipment is operating, but it does 
demonstrate how the hardware really works. A flight test is the 
ultimate test, again taken with the knowledge that it is probably 
not the extreme but something more like the middle of the 
environmental and systems performance. 

Good understanding of a problem and its solution always 
relies on a combination of all these methods. Be sure to lead 
your leaders by using all the tools you have at your disposal. 

At the end of the day, decisions in space flight always come 
down to a risk trade. Our business is not remotely safe, not in the 
sense that the public, the media, or our legislators use the term. 
Everything we do has a risk, cost, schedule, or performance 
trade-off. For your leaders to make an appropriate decision, you 
need to educate them, lead them, talk with them, and engage 
them in the discussion until full understanding takes place. 

If s your job. # 
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